Superseded by #3 - #2

… support

Code review findings, fixed:

* Linux: a live lock owner was reported as an orphan, so any waiter stole
  its write lock. Process.StartTime is derived per process from a wall-clock
  boot-time snapshot, so the value an owner records and the value another
  process computes for it differ by milliseconds and never compare equal.
  Record and compare /proc/<pid>/stat starttime (kernel ticks) instead.
  Values written by 3.0.0 (negative DateTime binaries) are treated as
  unknown and fall back to the PID-only check.

* Orphan recovery only probed the owner at the start of a wait and at 75% of
  the timeout, so a wait with Timeout.InfiniteTimeSpan never recovered from
  an owner that died later. Probe every 250 ms instead.

* Dispose() unmapped the header while another thread was still spinning in
  TryAcquireWriteLock/TryAcquireReadLock, which is a process-fatal
  AccessViolationException. Lock waiters now register with Dispose(), leave
  with ObjectDisposedException, and Dispose() waits for them before unmapping.

* ReleaseWriteLock silently ignored a release from a non-owner thread, so
  `await` inside a lock scope left the lock held forever with no diagnostic.
  It now throws SynchronizationLockException, as do the StructuredMemory
  WriteLock/ReadLock guards when disposed on another thread (before touching
  any state, so the owning thread can still release correctly).

* TypeLayoutFingerprint used Marshal.SizeOf/OffsetOf, which reject generic
  types, so ValueTuple/KeyValuePair<,> failed in every typed container.
  Fall back to a managed-layout descriptor for those types. Fingerprints of
  types that already worked are byte-for-byte unchanged (pinned by a test),
  so 3.0.0 and newer processes can still share regions.

Tests: cross-process regression tests (live owner, infinite and finite wait
recovery) with a new hold_write_lock worker role, Dispose-with-waiter,
guard-on-another-thread, generic struct and pinned fingerprint tests. Two
tests that asserted the old "silently ignored" behaviour now expect the
exception.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01JHFt4htvPpb8R3ZeepEVF8

Disposing a region while another thread is inside Read/Write or a typed
queue unmaps memory that thread is still using, which terminates the
process with an AccessViolationException. Measured with three threads busy
polling a ConcurrentQueue on a 4-core machine, Dispose killed the process
in 12 of 12 runs of 400 races each.

Tracking in-flight calls would close the race but is not affordable on the
lock-free paths: two interlocked operations per call made a single-thread
queue round trip about 9x slower (3.3 ns -> 31 ns), two threads exchanging
items about 17x slower (about 70 M -> 4 M msgs/s) and MemoryRegion.Read
about 2x slower. Striping the counter per CPU did not help.

Instead, MemoryRegion.Dispose now keeps the mapping for
MemoryRegion.DisposeGracePeriod (default 10 ms, process-wide, Zero
disables) after the instance is marked disposed. New calls already fail
with ObjectDisposedException, so the pause lets calls that were past their
check finish. Measured: 12 of 12 runs of 400 races survive with the
default, and 8 oversubscribed pollers on 4 cores still failed in 1 of 8
runs (0 of 8 at 25 ms). It is a mitigation, not a guarantee, and says so
in the XML docs and the README: the only complete protection is to stop
and join every thread that uses an instance before disposing it.

Tests: the grace period setting, that Dispose honours it, and a busy-poll
Dispose race that kills the process without the grace period.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01JHFt4htvPpb8R3ZeepEVF8

* SharedArray did not dispose its region when the header check failed
  (another element type or length), so the mapping and, on Linux, its file
  descriptor stayed open until the finalizer ran. The other containers
  already clean up; do the same here.

* SharedArray and StructuredMemory expose no statistics, yet their region
  updated its read/write counters with interlocked operations on every
  access. Turn the counters off for these internal regions: no observable
  change, SharedArray<long> get 24 -> 18 ns and set 15.6 -> 5.9 ns.

* Every automatically locked StructuredMemory call (values wider than
  8 bytes, strings, blobs, arrays) allocated 104 bytes: a new delegate for
  the lock guard (method group conversion) plus a Stopwatch instance inside
  the lock wait. Cache the delegates per instance and time the lock waits
  with Stopwatch timestamps. Measured 104 -> 0 bytes per call and
  Write<Guid> 311 -> 190 ns.

Tests: failed open leaves no extra file descriptor (Linux), and automatically
locked access allocates nothing per call.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01JHFt4htvPpb8R3ZeepEVF8